For speed of communications and cost effectiveness, individuals, businesses, and other organizations frequently exchange electronic data through e-mail, the Internet, and other networks and systems. For example, companies increasingly rely on the Internet to obtain loosely coupled Web services deployed by Web service providers on application-based servers, which are computers on networks that manage the networks.
Web services are business-enterprise computer applications that can be utilized singly or collectively to accomplish a wide range of intended purposes, such as determining health-care patients' eligibility for benefits, submitting health-care claims, and providing stock quotes. Web services help companies dramatically cut costs, increase revenues, and improve competitive agility by combining existing, heterogeneous systems into cross-functional, multi-company applications.
FIG. 1 shows an example of how multiple chained Web services are typically used as part of a Web service application for the filing and payment of medical insurance claims. Chained Web services are loosely connected Web services that may reside on different servers and that may be provided by separate businesses. Web services applications are computer applications that use Web services singly or collectively to accomplish intended purposes. A Web service provider employs a server 100 running a Web portal page 200 and a Web service application 300.
A Web portal page 200 is a Web site interface that a person can reach over the Internet. Web site interfaces typically are computer-programmed modules that allow end-users to select variables and parameters from easy-to-use visual displays or to type in this input, save the information through selecting a save option, and have their selections automatically applied by computer subsequently, without those users having to program the information manually.
In the example for FIG. 1, an attendant at a clinic computer 150 can use the Internet, through a wired link 144, a telephone network 130, and another wired link 142, to reach the portal Web page 200 on the Web service provider server 100. The attendant can then use the portal Web page 200 to fill out a claim file form 220 for one of the clinic's patients and submit the form as an electronic data file to Web service application 1 300.
Other means for submitting claims also exist. For example, an attendant at a clinic computer 150 might use link 144, network 130, and link 142 for a machine-to-machine transmission of a claim file directly to Web service application 1 300. Many kinds of wired and unwired links and networks could be used for this machine-to-machine transmission, such as the Internet, a private LAN (Local Area Network), a wireless network, a TCP/IP (Transmission Control Protocol/Internet Protocol) network, or other communications system.
To continue with the example, Web service application 1 300 receives each claim file through Web service 1 410, which relays the claim data in an electronic data file back over link 142, network 130, and link 143 to server 2 182. If necessary, Web service 2 420 then transforms the format of the claim file to a format that Web service application 1 300 can use for its full 30 operations. For example, a claim file might have been sent in NSF (National Standard Format) format, but Web service application 1 300 might require HIPAA (Health Insurance Portability and Accountability Act) format.
After the claim file is transformed to the correct message format, Web service 2 420 relays the claim data in an electronic data file back over link 143, network 130, and link 145 to server 3 184 and Web service 3 430, which is used to validate the claim file. In turn, Web service 3 430 relays the claim data in an electronic data file back over link 145, network 130, and link 147 to server 4 186 and Web service 4 440. Web service 4 440 is used to send the claim data in an electronic data file back over link 147, network 130, and link 148 to an insurance company-server 170 for payment to the clinic.
Electronic Data Interchange (EDI)
To help establish compatibility for electronic data exchanges such as the one outlined in FIG. 1, the American National Standards Institute (ANSI) Accredited Standards Committee (ASC) has developed a set of standards for electronic data interchange (EDI) called the X12 standards, which defines the content and structure for data contained in electronic data files. For example, in EDI X12, a standard HIPAA (Health Insurance Portability and Accountability Act) “837P” document represents an electronic data file used for filing patient claims to a health insurer. To follow the example used with FIG. 1, the electronic data file created by Web service 1 410 could be an 837P document.
Example of an EDI Document
An EDI document is a flat list of text, the divisions of which are not easy to determine. The following, abbreviated code shows a typical EDI document:
ISA*00*    *00*    *ZZ*WEBIFYSE    *ZZ*00AAA*020220*1243*U*00401*100000034*0*T*:~GS*HS*WEBIFYSE*00AAA*20020220*2314*123456789*X*004010X092A1~ST*270*3120~BHT*0022*13*10001234*19990501*103045*RT~HL*1**20*1~NM1*PR*2*SampleBCBS*****FI*999999999~HL*2*1*21*1~NM1*1P*2*SampleClinic*****FI*888888888~REF*1J*0035~HL*3*2*22*0~TRN*1*93175-012547*9323233345~NM1*IL*1*SMITH*JOHN*M***MI*333440623~DMG*D8*19510918~DTP*472*RD8*20031201-20031201~EQ*30**FAM*GP~SE*14*3120~GE*1*123456789~IEA*1*100000034~
In this EDI document, the elements ST and SE represent the start and end of a business transaction, called an EDI transaction, that may contain many additional elements, as shown in the following segment extracted from the example given above:
ST*270*3120~BHT*0022*13*10001234*19990501*103045*RT~HL*1**20*1~NM1*PR*2*Sample BCBS*****FI*999999999~HL*2*1*21*1~NM1*1P*2*SampleClinic*****FI*888888888~REF*1J*0035~HL*3*2**22*0~TRN*1*93175-012547*9323233345~NM1*IL*1*SMITH*JOHN*M***MI*333440623~DMG*D8*19510918~DTP*472*RD8*20031201-20031201~EQ*30**FAM*GP~SEExample of an EDI Transaction
The following line shows a typical segment of an EDI transaction in an 837P document:NM1*H*DOE*JOHN*78747
In this example, the letters “DOE” might represent the last name of a specific individual. The field where “DOE” appears might indicate the last name of a patient submitting a claim. Similarly, the numbers “78747” might represent a specific individual's zip code and the field where “78747” appears might indicate the zip code of a patient filing a claim.
Problems with EDI Documents
Programmers and automatic programs often must work with multiple segments of EDI transactions, comprising hundreds of lines of difficult-to-read code, to create, test, and correct related EDI documents and transactions.
For example, in the system shown in FIG. 1, suppose that the person who submits a claims file mistypes a patient's zip code. In such a case, Web service 3 430 might run an error-checking program and compare patient names and zip codes in claims with those in a central database. After discovering the erroneous zip code, Web service 3 430 might then run a correction program to substitute the correct zip code. However, creating such error-detection and correction programs with current methods typically requires low-level string manipulation of code, involving counting the stars (*) and characters in EDI segments and fields to find the desired data and create programs to manipulate it.
Alternately, human operators might have to become involved to ensure that the patient's claims data is correct, by sorting through potentially hundreds of lines of code and making changes manually.
Furthermore, the data in specific fields in EDI segments may have different meanings in different contexts, so that the same field in different 837P documents may need to be interpreted differently. For example, a patient from Texas who is injured while on vacation in California and who files a claim from a clinic there might have the clinic's California zip code attached to his claims file instead of the Texas zip code that would normally be associated with him for routing his claim. Such context-based differences may require much additional time and effort by programmers or operators who have to sort through EDI segments and interpret them.
Because of these problems, current automatic or manual methods of finding, revising, and otherwise manipulating specific fields in large EDI transactions are time consuming and expensive.
US patent application number 20020049790 to Ricker describes a method to express EDI document as XML documents with tags that give human-readable context to the data near that tag. But that method does not address the present invention's object-based method of creating a SEF (Standard Exchange Format) parser and EDI parser generator to make EDI transactions more efficient to read and modify by both human operators and machines.
Therefore there is a need for a method and system that provides a more automatic method for efficiently processing data in Electronic Data Interchange (EDI) transactions, for example for reading and modifying such.